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(57) Abstract: A method and a device for initiating the bypassing of a pair of transcoding operations that are performed in series by 
a first transcoder arranged together with a first communication terminal on a local side of a communication network and by a second 
transcoder arranged together with a second communication terminal on a distant side of the communication network are described. 
The method includes receiving from the distant side information about an encoding format currently in use on the distant side and 
about encoding capabilities of the distant side and transmitting to the distant side information about an encoding format currently in 
use on the local side and about encoding capabilities of the local side to enable on one or on both sides a change of the encoding 
format currently in use prior to initiating the bypassing of the transcoding operations. 
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DESCRIPTION 



Bypassing Transcoding Operations in a Communication Network 
Field of the Invention 

The present invention relates to the call set-up in a communication network. More 
specifically, the invention relates to the bypassing of a pair of transcoding operations 
that are performed in series by a first transcoder arranged on a local side of the 
communication network and by a second transcoder located on a distant side 
thereof. 

Background of the Invention 

In digital systems for mobile communication speech signals are encoded by a speech 
encoder in order to reduce the data rate and for saving bandwidth, In a call originat- 
ing in a mobile terminal and terminating in a mobile terminal, a so-called mobile-to- 
mobile call, the speech signal usually is encoded and decoded twice. In the originat- 
ing mobile terminal the speech signal is encoded a first time before the encoded 
signal is sent over the air to a first network node, e.g. a base station. A first 
transcoder decodes the encoded signal, which it receives from the first network 
node, into a so-called a-law/ja-Iaw signal which is commonly used in fixed communi- 
cation networks. The decoded signal is routed in the fixed network to a second 
network node, e.g. a second base station. Before the second network node can 
transmit the signal, the signal is encoded again in a second transcoder. The encoded 
signal is emitted by the second network node and is decoded in the terminating 
mobile terminal. The speech signal flow in the opposite direction is handled symmet- 
rically. 

As in this configuration two encoder/decoder pairs are lined up (the encoder of the 
originating mobile terminal and the decoder of the originating transcoder are re- 
garded as a first pair and the encoder of the terminating transcoder and the decoder 
of the terminating mobile terminal are regarded as a second pair), this configuration 
is called a speech codec "tandem". The key inconvenience of a tandem configuration 
is the speech quality degradation introduced by the double transcoding. This degra- 
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dation is usually more noticeable when the speech codecs are operating at low 
transmission rates. 

When the originating and the terminating mobile terminal are using the same type of 
speech codec, it is possible to transmit the speech frames received from the originat- 
ing mobile terminal to the terminating mobile terminal without the need to activate 
the transcoding functions in the first and the second transcoder. As then there is only 
one pair of encoder and decoder (that is, the encoder in the originating mobile . 
terminal and the decoder in the terminating mobile terminal) involved, this configura- 
tion is called Tandem Free Operation (TFO). In modern networks, like UTMS, it is 
even possible to discard the whole transcoder hardware. This is then called a 
Transcoder Free Operation (TrFO) instead of e.g. the usual a-law/|a-law signal. In 
TFO and TrFO mode the encoded and compressed speech signal is transmitted over 
the fixed network. Besides the improvement of the speech quality by avoiding double 
transcoding TFO also saves costs as the compressed signal needs less bandwidth in 
the fixed network and power is saved since transcoding is bypassed twice. All neces- 
sary methods for negotiating, establishing and maintaining a Tandem Free Operating 
connection (TFO connection) are standardized for codec types without configuration 
parameters (e.g. in GSM 08.62 for GSM_FR, GSM_HR and GSM_EFR) or for more 
complex codec types (e.g. the adaptive multi-code rate (AMR)) by the 3 rd Generation 
Partnership Project (3GPP). 

In Technical Specification 3G TS 28.062 V.5.0.0; 3 rd Generation Partnership project; 
Technical Specification Group Services & Systems Aspects; In-band Tandem Free 
Operation (TFO) of Speech Codecs; Stage 3; Service Description; Release 5, which is 
exemplary in respect of bypassing serial transcoding operations, various aspects of 
TFO for 3GPP are illustrated. TFO is activated and controlled in 3GPP by so-called 
Transcoder Units after the completion of the call set-up phase at both ends of a 
mobile-to-mobile call configuration. The TFO protocol is fully handled and terminated 
in the Transcoder Units. For this reason, the Transcoder Units cannot be bypassed in 
TFO. This is the key difference in comparison with TrFO which is defined in 3GPP TS 
23.153. In return, the Transcoder Units continuously monitor the normal TFO and 
can terminate TFO as soon as necessary with limited impact on the speech quality. 

Before TFO is activated, the Transcoder Units exchange conventional 64 kbit/s PCM 
speech samples encoded according to a-law.or u-law. The Transcoder Units can also 
exchange TFO messages by stealing the least significant bit in every 16th speech 
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sample (see annex A of 3GPP TS 28.062 V5.0.0 for the specification of the TFO 
message transmission rules and clauses 6 to 8 for the description of the TFO proce- 
dures and message contents). 

If compatible speech codec types and configurations are used at both ends of the 
mobile-to-mobile call configuration, the Transcoder Units automatically activate TFO. 
If incompatible speech codec types and/or configurations are used at both ends, then 
a codec mismatch situation exists. TFO cannot be activated until the codec mismatch 
is resolved. This capability is an optional feature involving other network elements of 
the Radio Access Network (RAN). 

Once TFO is activated, the Transcoder Units exchange TFO frames carrying com- 
pressed speech and in-band signaling, the structure of which is derived from the 
GSM TRAU frames defined in the 3GPP TS 48.060 and 48.061 (see clause 5). The 
exchange of TFO messages is still possible while TFO is active. In this case, the 
stealing process will result in embedding a message in the synchronization pattern of 
the TFO Frame. 

If the Transcoder Units find that the codec types currently used by both mobile 
terminals are compatible they will immediately enter into a TFO mode. Although the 
mobile terminals often support a codec type with better properties (e.g. better 
speech quality or better data rate) than the currently used codec type, very often 
they will not start with the optimal codec type because only the codec type currently 
in use is signaled. If on the other hand both radio subsystems would always report 
the best codec type supported by the respective mobile terminal no agreement will 
be found and the communication will be started in tandem mode, although a TFO 
mode would have been possible. 

Although certain procedures ensure that in the course of the communication the 
communication connection can be switched to a common codec type and thus TFO 
can be enabled later on, the establishment is significantly delayed and the signal 
distortions in an initial tandem operation mode are inconvenient. Therefore, one 
could think about reporting a codec type with lower properties but that is widely 
spread in order to establish TFO very early. As further on messages are exchanged 
that report a list of supported codec types of each terminal, in the course of the 
connection the codec type in use may be changed to a better codec type. However 



WO 03/092312 



PCT/EP03/04268 



-4- 

the users of the mobile terminals will experience the change of the codec while the 
TFO is established as (clicking) noise and may be irritated. 

It is an object of the invention to improve the bypassing of two or more transcoding 
operations that are performed in series. It is a further object of the invention to allow 
an efficient protocol version handling. 

Summary of the Invention 

According to a first aspect, the invention proposes a method of initiating the bypass- 
ing of a pair of transcoding operations performed in series by a first transcoder 
arranged together with a first communication terminal on a local side of a communi- 
cation network and by a second transcoder arranged together with a second com- 
munication terminal on a distant side of the communication network. The method 
comprises receiving from the distant side information about an encoding format 
currently in use on the distant side and about encoding capabilities of the distant 
side, and transmitting to the distant side information about an encoding format 
currently in use on the local side and about encoding capabilities of the local side to 
enable on one or on both sides a change of the encoding format currently in use 
prior to initiating the bypassing of the transcoding operations. 

Thus a change of the encoding format may be performed on the basis of an evalua- 
tion of local and distant encoding information, like the encoding format currently in 
use and the encoding capabilities, before the transcoding operations are bypassed. 
This allows enter an operational mode bypassing the transcoding operations using an 
encoding format that is beneficial from the point of view of system operators and 
users. The encoding information may be included in an initial message requesting 
bypassing of the transcoding operations. 

A decision about the change of the encoding format may be performed even if 
compatible encoding formats are currently used on both sides. Thus, in the case of 
compatible encoding formats the transcoding operations may not be automatically 
bypassed but it may be decided if the current encoding formats, although being 
compatible, actually constitute the best configuration available. 

The information on the encoding capabilities of the distant side may be used to 
determine an alternative encoding format that is supported on both the local and the 
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distant side. The change of the encoding format may then effected on the basis of 
the alternative encoding format, e.g. by switching to this alternative encoding format. 

The information about the encoding capabilities of the local side or distant side may 
include the version of a bypassing protocol, such as a TFO protocol version, sup- 
ported by the local or distant transcoder. This allows for example to detect possible 
protocol conflicts at a very early stage and to decide if and how the conflicts can be 
resolved prior to bypassing the transcoding operations. In addition or as an alterna- 
tive to a version of a bypassing protocol, the information about the encoding capabili- 
ties of the local or distant side may include a list of encoding formats supported by 
the local or distant communication terminal or transcoder. For example the list of 
encoding formats may specify preferred encoding formats or alternative encoding 
formats to the encoding format currently in use on a particular side of the communi- 
cation network. 

As has been mentioned above, the local and distant encoding information, including 
the encoding format currently in use and the encoding capabilities, may form the 
basis for a decision regarding a possible change of the encoding format currently in 
use. A change of the encoding format may be effected with the purpose of establish- 
ing an optimal encoding configuration on the basis of compatible encoding formats 
on both sides. If for example one side or both sides currently use narrowband 
encoding formats but both sides support wideband encoding formats, it may be 
decided on one side or on both sides to switch to the usually more preferable wide- 
band encoding format prior to entering an operational state that bypasses the 
transcoding operations. 

If one side changes its encoding format it may notify the opposite side thereof. Such 
a notification may be performed prior to entering an operational mode that bypasses 
the transcoding operations. 

The bypassing protocol that is used for initiating the bypassing of the transcoding 
operations may include different states. For example the bypassing protocol may 
include a contact state which may be entered as soon as it is clear that compatible 
encoding formats exist and which may precede the bypassing of the transcoding 
operations. The bypassing protocol may-further include an operational state in which 
the transcoding operations are bypassed. 
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Based on the local and distant encoding information available on one of the two sides 
it may be decided to change the encoding format on one or and both sides. This 
decision may be performed prior to switching into the contact state or in the contact 
state. The actual change of the encoding formats may be performed in the contact 
state. A switch from the contact state into the operational state may be performed 
after one or both sides have signaled that the encoding format currently in use will 
be or has been changed. In the case the of incompatible protocol versions it may be 
decided to abort the bypassing protocol, and to remain in tandem operation, prior to 
entering the contact state or in the contact state, i.e. at a rather early stage of the 
call. 

The information about the encoding format may relate to various aspects depending 
on the specific communication scenario. It may for example include a codec type that 
is used on a specific side to encode speech signals into an encoded data representa- 
tion. However, the invention is not restricted to the transcoding of speech signals but 
may be applied to handle the transcoding of encoded signals regardless of their 
particular content. 

The information on the encoding capabilities of one side may be used on the other 
side to look up a subset of a list of encoding formats that is supported on the distant 
side. The list of supported encoding format may for example include a supported 
codec list (SCL). The subset or encoding formats supported on the distant side may 
then be compared with the encoding formats supported on the local side. On the 
basis of this comparison a change of the encoding format may be effected to initiate 
bypassing of the transcoding operations using the best encoding format in common. 

The local and distant encoding information including the information about the 
encoding format currently in use and about encoding capabilities may be signaled 
between the local side and the distant side in various ways. For example the encod- 
ing information may be included in dedicated messages. As another example, the 
encoding information may be included in a message requesting the initiation of a 
bypassing protocol or in a message acknowledging such a request. 

In the case the encoding information is included in messages that are used for 
additional signaling purposes, the information about encoding capabilities may be 
appended in the form of one or more individual information blocks to the message. 
For example a first appended block may include the version of a bypassing protocol 
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and an indicator that indicates if the first appended block is followed by one or more 
further appended blocks that may include a list of one or more encoding formats 
supported by the respective side. 

As has already been mentioned, the method set forth above can be performed in 
context with setting up of a TFO between two communication terminals. The inven- 
tion may also be practiced in similar scenarios that involve a series of two or more 
transcoding operations. 

If at least one of the communication terminals uses at least one codec type to 
encode speech signals into an encoded representation, messages may be sent 
between the two transcoders to determine if the communication terminals have at 
least one codec type in common. Should this be the case a data connection may be 
established between the two communication terminals without having the need to 
insert transcoding functions into a signal path between the two communication 
terminals. The messages exchanged between the transcoders may include a first 
message that contains information about the encoding format currently used by a 
particular communication terminal and further information about the encoding 
capabilities of the particular communication terminal or transcoder. After the first 
messages have been exchanged, second messages may be exchanged between the 
transcoders as a response to the first messages. The second messages may be 
exchanged if both reported codec types match or regardless of such a match. 

According to a further aspect, the invention relates to a method of initiating a TFO in 
a communication network for a speech communication between a first communica- 
tion terminal and a second communication terminal, wherein at least one of the 
terminals uses at least one codec type to encode speech signals into an encoded 
data representation and wherein the communication network includes a first 
transcoder and a second transcoder. Messages are sent from the first transcoder to 
the second transcoder and vice versa to determine if both communication terminals 
have at least one codec type in common and, if this is the case, to establish a data 
connection between the first communication terminal and the second communication 
terminal without having the need to insert transcoding functions into a signal path 
between the first and the second communication terminal. The method comprises 
the step of exchanging messages between the transcoders that contain information 
on the encoder type currently used by the communication terminals and further 
information on encoding capabilities of the respective communication terminal, and 
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the further step exchanging a further message between the transcoders as a re- 
sponse to the first messages e.g. if both reported codec types match or regardless of 
such a match. 

The information on encoding capabilities may include a TFO version number that is 
used by the receiving transcoder to look up a subset of an active codec set that is in 
a mandatory manner supported in the specific TFO version. The transcoder may 
compare this subset with the codec types supported by the associated communica- 
tion terminal and the best codec type in common may be chosen to enter into TFO. 

The present invention may be implemented as software, as a hardware solution, or 
as a combination thereof. Thus, the invention also relates to a computer program 
product with program code portions for performing the individual steps of the 
invention when the computer program product is run on one or more computing 
units of the communication network. One or more of the computing units may be 
part of or co-located with a transcoder. The computer program product may be 
stored on a computer-readable recording medium. 

As regards a hardware solution, the invention relates to a device for processing 
signals in context with the initiation of the bypassing of a pair of transcoding opera- 
tions performed in series by a first transcoder arranged together with a first commu- 
nication terminal on a local side of a communication network and by a second 
transcoder arranged together with a second communication terminal on a distant 
side of the communication network. The device comprises a component for receiving 
information about an encoding format currently in use on the distant side and about 
encoding capabilities of the distant side and further includes a component for trans- 
mitting information about an encoding format currently in use on the local side and 
about encoding capabilities of the local side to enable on one or on both sides a 
change of the encoding format currently in use prior to initiating the bypassing of the 
transcoding operations. Additionally, the device may comprise a component for 
generation the information about the encoding format currently in use on the local 
side and about the encoding capabilities of the local side 

The device may be included in a transcoder or in any other unit of the communica- 
tion network. If the device is included in a transcoder, the transcoder may further 
comprise a component for evaluating local and distant encoding information and for 
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controlling the change of the encoding format. Thus, the bypassing protocol may 
completely or partially be handled by the transcoder. 

The invention further relates to a communication system including the transcoder 
described above and a separate controller for evaluating local and distant encoding 
information and for controlling the change of the encoding format. For example, the 
controller may be part of a base transceiver station (BTS) or a base station controller 
(BSC). 

Brief Description of the Drawings 

A more complete understanding of the method and device of the present invention 
may be obtained by reference to the following detailed description when taken in 
conjunction with the accompanying drawings, wherein: 

Fig. 1 is a schemetical diagram of the functional entities handling TFO; 

Fig. 2 illustrates an exemplary TFO configuration between a GSM network and 

a 3G network; 

Fig. 3 is a schematical diagram of the shortest possible TFO_ REQ message; 

Fig. 4 is a schematical diagram of the shortest possible TFO_ REQ_L message; 

Fig. 5 is a schematical diagram of a TFO_REQ message including detailed 

encoding information; 

Fig. 6a is a table illustrating the content of a TFO version extension block; 

Fig. 6b is a table illustrating the content of a codec attribute head extension 
block; 

Fig. 7 is a schematical diagram of a TFO protocol state machine with the most 

important transitions; 

Fig. 8 is an exemplary flow chart depicting the process of immediate codec 

type optimization according to the invention; 



WO 03/092312 



PCT/EP03/04268 



- 10 - 

Fig. 9 is a flow chart depicting TFO establishment after the immediate codec 

type optimization of Fig. 8; and 

Fig. 10 is a table illustrating an exemplary TFO version handling mechanism. 

Description of the Preferred Embodiment 

In the following description, for purposes of explanation and not limitation, specific 
details are set forth, such as particular embodiments, signal formats, etc. in order to 
provide a thorough understanding of the present invention. It will be apparent to one 
skilled in the art that the present invention may be practiced in other embodiments 
that depart from these specific details. In particular, while the following embodiment 
is described herein below in context with an exemplary TFO configuration between a 
GSM network and a 3G network, the present invention is not limited to such an 
implementation. It can be utilized in any transcoding environment that allows to 
bypass two or more transcoding operations that are performed in series. Moreover, 
those skilled in the art will appreciate that the functions explained herein below may 
be implemented using individual hardware circuitry, using software functioning in 
conjunction with a programmed microprocessor or general purpose computer, using 
an application specific integrated circuit (ASIC), and/or using one or more digital 
signal processors (DSPs). 

In the following, the invention will be described in context with the technical specifi- 
cation 3G TS 28.062 V.5.0.0 that has already been mentioned above. The technical 
content of this specification as regards TFO is herewith incorporated by reference. 

Fig. 1 gives a schematical overview over the functional entities of a communication 
system that are involved when TFO is to be established. The communication system 
is shown in simplified form and is illustrative of a call routing mechanism between 
two wireless subscriber units terminal A and terminal B. The subscriber units de- 
picted in Fig. 1 may be mobile terminals or fixed site terminals. In the example 
depicted in Fig. 1 the terminals A and B are exchanging speech signals. Each terminal 
A and B is attached via a respective access network A and B to a transcoder A and B, 
respectively. The two transcoders A and B communicate via a digital network that 
includes additional in path equipment (IPE). 
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Each of the two terminals A and B and each of the two transcoders A and B com- 
prises a decoder and an encoder. In the configuration shown in Fig. 1, the individual 
speech encoder/decoder pairs (speech codecs) are in tandem operation. However, 
the transcoders A and B are each equipped with a control logic (TFO_ Protocol) that 
allows to enter a TFO mode. In such an operational mode the individual transcoders 
A and B are still present in the signal path between the terminals A and B, but their 
respective transcoding functions are bypassed. As becomes apparent from Fig. 1, the 
TFO protocol is fully handled and terminated in the transcoders A and B. 

Before TFO is activated, the transcoders A and B exchange conventional PCM speech 
samples at 64 kbit/s that are transmitted via the digital network. Once TFO is acti- 
vated, the transcoders A and B exchange TFO frames carrying compressed speech 
and in-band signaling. 

In principle, the communication scenario depicted in Fig. 1 applies regardless of the 
specific call configuration, i.e. regardless of the type of access network involved. In 
the following the TFO configuration between a GSM network and a 3G network will 
exemplarily be described in more detail with reference to Fig. 2. The underlying 
principles can, however, readily be applied to TFO configurations involving the same 
or two different GSM networks or TFO configurations involving the same or two 
different 3G networks. 

The communication scenario depicted in Fig. 2 includes on the GSM side a mobile 
station (MS), a base transceiver station (BTS), a base station controller (BSC), a 
transcoder and rate adaptor unit (TRAU) and a mobile switching center (MSC). On 
the 3G side a user equipment (UE), a node B, a radio network control (RNC) and a 
media gateway (MGW) with a transcoder (TC) and an MSC server are arranged. The 
GSM network and the 3G network communicate via a digital network including IPE. 

Each of the TRAU and the TC comprise an interface for receiving information about 
an encoding format (codec type) currently in use on the respective distant side and 
about encoding capabilities (TFO protocol version and/or a list of selected alterna- 
tively supported codec types) of the respective distant side and for generating and 
transmitting information about an encoding format currently in use on the respective 
local side and about encoding capabilities of the respective local side. A software 
routine running on an internal processor of each of the TRAU and the TC allows the 
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evaluation of the local and distant encoding information and a control of the locally 
used encoding format. 

As has been mentioned before, the TFO protocol is fully handled on the GSM side by 
the TRAU and on the 3G side by the TC. In the following it is assumed that the GSM 
network is arranged on the local side and the 3G network on the distant side. 

As soon as the local TRAU receives and sends PCM speech samples, it initiates the 
TFO negotiation and pre-synchronizes IPEs. The IPEs will then let TFO messages 
pass transparently. The distant TC may initiate the same procedure at the same time. 

At the beginning of the TFO negotiation the local TRAU sends a so-called TFO_REQ 
message, indicating its system identification (GSM) and the speech codec type 
currently used between the MS and the TRAU. If the distant TC supports TFO, it will 
answer by a so-called TFO_ACK message. The distant TC may send TFO_REQ 
messages to the local TRAU and receive an TFO_ACK message from the local TRAU 
at the same time. Should the distant TC not answer with a TFO_ACK message, e.g. 
because the distant TC does not support TFO or because TFO is disabled there, the 
local TRAU aborts the TFO protocol after having sent several TFO_REQ messages 
and returns to its normal mode. It continues, however, to monitor if there are any 
TFO messages inserted in the PCM samples received from the distant TC. 

As has become apparent from the above, the TFO_REQ message identifies the 
source of the message as a TFO capable device. TFO_REQ, as seen from the sender, 
contains the following parameters: 

the system identification of the sender, 
the specific local signature of the sender, 
the codec type locally used at the sender side, 

possibly additional attributes for the codec type locally used at the sender 
side, 

possibly additionally the TFO protocol version supported at the sender side, 
possibly additionally alternative codec types (e.g. a short form of the Co- 
decJJst as defined in TS 28.062 V.5.0.0) , 
possibly additionally a.future TFO extension. 
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The TFO_ACK message, which is the response to the TFO_REQ message, contains 
the corresponding parameters as TFO_REQ for the opposite side. The only exception 
is the local signature that is replaced in the TFO_ACK message by the reflected 
signature as copied from the received TFO_REQ message. 

If during the TFO negotiation on the basis of TFO_REQ and TFO_ACK messages a 
codec mismatch between the local side and the distant side is determined, as well as 
for sporadic updates of information, TFO_REQ_L and TFO_ACK_L messages may be 
exchanged. 

TFO_REQ_L messages contain the following parameters: 

system identification of the sender, 
the specific local signature of the sender, 
the codec type locally used at the sender side, 
a local codec list of alternative codec types, 

possibly additional attributes for the used and the alternative codec types 
possibly additionally the TFO protocol version, 
possibly additionally a future TFO extension. 

A TFO_ACK_L message is the response to a TFO_REQ_L message. The TFO_ACK_L 
message contains the corresponding parameters as the TFO_REQ_L message for the 
opposite side, except for the local signature which is replaced by the reflected 
signature as copied from the received TFO_REQ_L message. 

Figs. 3 and 4 show the configuration of the shortest possible TFO_REQ message and 
of the shortest possible TFO_REQ_L message. The shortest TFO_REQ_ message 
takes 140 msec for transmission, whereas the shortest TFO_REQ_L message takes 
180 msec. 

The structure of the TFO messages depicted in Figs. 3 and 4 follows the generic in- 
band signaling (IS) message principle. More specifically, the messages depicted in 
Figs. 3 and 4 include a header block consisting of a 20 bit long sequence that is 
followed by a command block of 10 bits identifying the TFO message as a TFO 
request. The third block is in each case a system identification block having a length 
of 20 bits and specifying the type of network from which the request originates (3G 
GSM, ....). 
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The fourth block of the TFO_REQ message depicted in Fig. 3 includes the local 
signature (SIG) of the sender, the locally used codec type and an indicator S which 
indicates that no further blocks are following (S = short). The fourth block of the 
shortest possible TFO_REQ_L message depicted in Fig. 4 is similar to the fourth block 
of the TFO_REQ message but includes an indicator L (long) which points at a codec 
list that is included in a fifth block. 

In order to enable a TFO negotiation that allows establishment of a TFO (i.e. bypass- 
ing of the transcoding operations that are performed by the local TRAU and the 
distant TC in Fig. 2) on the basis of an optimal codec configuration on both sides, 
one or more additional blocks including encoding information may be appended to 
the shortest possible TFO_REQ message depicted in Fig. 3. Such an extended 
TFO_REQ message is shown in Fig. 5. 

The extended TFO_REQ message of Fig. 5 includes a fifth block called TFO version 
extension block that contains information about the encoding capabilities of the 
respective transcoder and additionally a selector. The information about the encoding 
capabilities relates to the TFO protocol version and subversion (Ver.Sver) supported 
by the respective transcoder. The selector (Sel) indicates if and which additional 
extension blocks are following. The exemplary TFO_REQ message shown in Fig. 5 
includes one additional extension block (sixth block). 

It should be noted that blocks similar to the fifth and sixth block of the TFO_REQ 
message depicted in Fig. 5 may be appended to the TFO_ACK message. Moreover, a 
block similar to the fifth block (TFO version extension block) of the TFO_REQ mes- 
sage of Fig. 5 may be appended to the TFO_REQ_L or the TFO_ACK_L message. In 
the following, the additional blocks of the TFO_REQ message of Fig. 5 will exempla- 
rily be described in more detail. 

The TFO version extension block (fifth block in Fig. 5) contains the TFO version (4 
bit) and TFO subversion (4 bit) that are supported by the respective transcoder. The 
supported TFO version and TFO subversion are indicative of the various codec types 
available to a particular transcoder, i.e. indicative of the particular transcoder's 
encoding capabilities. 



WO 03/092312 



PCT/EP03/04268 



- 15 - 

The TFO version extension block further includes the selector which is used to 
indicate the number and content of additional extension blocks following the TFO 
version extension block (if any). The selector code "00000" indicates that no further 
extension block is following. If the selector code is set to "00001" this indicates that a 
particular transcoder supports alternative codec types, which are specified in one or 
more further extension blocks following the TFO version extension block. The selec- 
tor is preferably only used in TFO_REQ or TFO_ACK messages (i.e. not used in 
TFO_REQ_L or TFO_ACK L messages) to provide information on alternative codec 
types at an early stage of TFO protocol, i.e. before TFO is established. 

For each alternative codec type that is offered during TFO negotiation, one codec 
attribute head extension block can be included in the TFO_REQ message. If the 
specified codec type requires additional attributes, then the required number of 
codec attribute extension blocks follow after the codec attribute head extension 
block. The one or more extension blocks following the TFO version extension block 
thus include information about the encoding capabilities on a particular network side 
in the form of a list of one or more (alternatively) supported codec types. A list of 
alternative codec types is terminated when the two EX bits at the end of a particular 
extension block indicate no further extension blocks ("00") and the next TFO mes- 
sage header is following. 

The exemplary content of the TFO version extension block is depicted in the table of 
Fig. 6a and the exemplary content of the codec attribute head extension block, which 
identifies the codec type and the number of additional extension blocks that will 
follow, can be gathered from the table of Fig. 6b. The codec attribute head extension 
block may proceed the codec attribute extension blocks of a codec type if this codec 
type needs additional attributes. 

The TFO version extension block and any additional extension blocks indicated by the 
selector may be the last extension blocks of a TFO_REQ, a TFO_REQ_L , a TFO_ACK 
or a TFO_ACK_L message. This is advantageous in order to provide compatibility with 
older protocol versions, which should be able to skip these extension blocks without 
being effected negatively. Thus, a high degree of compatibility between different 
protocol versions can be achieved. Usually, only messages generated on the basis of 
protocol versions higher than a particular version will (and actually should) include 
TFO version extension blocks. If no TFO version extension blocks are detected in a 
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TFO_REQ or similar message, a protocol version lower than a specific version can be 
assumed by the receiving side. 

In the following, an exemplary immediate codec type optimization scenario during 
establishment of a TFO mode for the network configuration depicted in Fig. 2 will be 
described with reference to Figs. 7 to 9. The term "immediate optimization" relates to 
the fact that it will be decided about a change of the codec types currently in use not 
only in the case of non-compatible codec types (codec mismatch), but also if com- 
patible encoding formats are currently used on both sides. Thus, the immediate 
decision can advantageously be performed at a very early stage of the call set-up 
without the necessity of a prior evaluation of the question whether or not the cur- 
rently used codec types are actually compatible. 

Fig. 7 shows a schematic diagram of a state machine, consisting of 17 states that 
describe the TFO protocol process. The five main states are initialization, establish- 
ment, contact, preparation and operation. These states will now be described in more 
detail for the exemplary protocol flow depicted in Figs. 8 and 9. 

Here it is assumed that both sides start with narrowband AMR (AMR-NB), but indi- 
cate that wideband AMR (AMR-WB) is supported also. Usually, such a situation will 
lead to an immediate TFO setup on the basis of AMR-NB. In the present immediate 
codec type optimization scenario, however, no immediate TFO setup in AMR-NB is 
performed because both sides can use better codec types and configurations. 

The initial state of the TFO protocol is the Not _Active state (see Figs. 7 and 8). In 
this state the TFO protocol is not active and the TRAU/TC work in a conventional 
way. The Not_Active state is left and a transition to a Wakeup state is performed 
when a new speech call is set up and/or when TFO gets enabled. In the Wakeup 
state the TFO protocol waits until PCM speech samples are received. Then a transi- 
tion to the First_Try state is performed and TFO_REQ messages similar to those 
depicted in Fig. 5 are exchanged between the local TRAU and the distant TC for a 
certain period of time. 

As becomes apparent from Fig. 8, each TFO_REQ message includes an indication 
that the sending side currently operates on AMR-NB codecs (AMR, NB-ACS). ACS 
stands for active codec set, which in the case of AMR further specifies this encoding 
format. Each TFO_REQ message additionally includes encoding information about the 
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encoding capabilities of sending side (Ver, AMR-WB). This encoding information 
comprises the version Ver of the supported TFO protocol as well as an indication of 
an alternatively supported encoding format (here: AMR-WB). 

After the TFO_REQ messages have been exchanged both the TRAU and the TC can 
utilize the obtained information on the encoding capabilities of the respective distant 
side locally to look up a subset of an ACS that is supported on the respective distant 
side. This subset is compared with the codec types supported on the respective local 
side so that the best codec type in common can be chosen for initiating TFO. 

As soon as the TRAU and the TC have received and evaluated the TFO_REQ message 
from the opposite side a Contact state can be entered because in the present case 
the codecs match and the ACSs are compatible. In cases where the codecs do not 
match and/or the ACS are not compatible a Mismatch state (if supported) is entered. 
During a codec mismatch resolution routine the TRAU and TC will then exchange 
their full codec capabilities (supported codec list, with the full range of parameters 
for these codecs) by sending TFO_REQ_L messages or so-called Con_Req frames. 
These are acknowledged by TFO_ACK_L messages or so-called Con_Ack frames, 
respectively. 

In the Contact state TFO_ACK messages need to be sent to check the transparency 
of the link to the opposite side. After the exchange of TFO_REQ and/or TFO_ACK 
messages it will be obvious that a preferred TFO configuration (AMR-WB) is possible 
if the codec type at the local and at the distant side are changed. In this situation the 
TFO protocol stays in the Contact state and performs an immediate codec type 
optimization, i.e. initiates a change of the encoding formats currently used by the 
local and the distant side. 

In general, an immediate codec type optimization routine is initiated each time both 
sides indicate a specific TFO version (e.g. both sides indicate a TFO version greater 
than or equal to 5.3, see Fig. 10) and, at the same time, the available information on 
alternative codec types indicates that a change of the local and/or distant codec type 
results in a TFO configuration with a higher preference level. Whenever new informa- 
tion about alternative codec types becomes available, the conditions for immediate 
codec type optimization set forth above are re-evaluated. A possible TFO decision 
scheme for codec type optimization is described in 3GPP TS 28.062 V.5.0.0, herewith 
incorporated by reference. Although this decision scheme relates to codec type 
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optimization at a later stage of the TFO protocol, it can also be applied in mecha- 
nisms for immediate codec type optimization. 

In the present case the TFO decision mechanism will indicate that in the scenario 
depicted in Fig. 8 a change of the codec type to AMR-WB on both sides is preferable, 
i.e. will result in an optimal TFO configuration. Both the local TRAU and the distant 
TC report the optimal AMR-WB configuration to initiate a change to AMR-WB on the 
respective air interfaces. As soon as each side has switched to AMR-WB, the opposite 
side is notified thereof with an appropriate TFO_ACK message reporting the currently 
used encoding format (AMR-WB) and (again) the respective TFO protocol version. 

As soon as the TFO_ACK indicating that the encoding format of the opposite side has 
been changed to AMR-WB has been received, the TRAU and the TC know that the 
optimal TFO configuration has been achieved and immediate codec type optimization 
is complete. Since an AMR-WB codec type has been selected, the TRAU and the TC 
send rate control commands downlink to their BTS/RNC in order to steer the uplink 
codec mode down to the TFO setup mode for a save TFO setup. Additionally, a 
further TFO_ACK message is sent to the opposite side and the TFO protocol transits 
into the Wait_RC state as depicted in Figs. 7 and 8. This Wait_RC state exists only 
when the locally used codec type is an AMR or AMR-WB codec. For all other codec 
types this state is not entered and all transitions go directly into the Konnect state, 
thus skipping the Wait_RC state (see Fig. 7). 

In the Wait_RC state the TFO protocol waits for the acknowledgment from the 
BTS/RNC that the rate control command has been received and executed. Then the 
TC sends a so-called TFO_TRANS message to bypass the IPEs, starts sending TFO 
frames and the TFO protocol transits into a Konnect state. 

In the Konnect state the TFO frames and possibly embedded TFO messages are sent 
as long as correct TFO messages are received. The first received TFO frame causes 
the transition from the . Konnect state into the Operation state. 

In the operation state, the main state of the TFO protocol, TFO frames are sent and 
received. Thus, the TFO connection is fully operating. As becomes apparent from Fig. 
9, a further codec type optimization commands Con_Req and Con_Ack may be sent 
in the operation state when TFO is established. 
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As has been explained above, the objective of immediate codec type optimization is 
to switch the codec type on the local and/or the distant side (if this results in a 
preferred TFO configuration) while the TFO protocol is in the Contact state, i.e. at a 
very early state of the TFO protocol. The required information to decide if immediate 
codec type optimization shall be performed is comprised in the TFO_REQ and 
TFO_ACK messages including the TFO version extension block and (optionally or 
mandatory) additional extension blocks specifying selected alternatively supported 
encoding formats. If a preferred TFO configuration becomes possible by changing 
the local and/or distant codec type, both sides remain in the Contact state as long as 
immediate codec type optimization is performed, i.e. until the local and/or the distant 
side has/have changed the codec type. After the switching, TFO protocol continues 
as usual. 

Immediate codec type optimization using information about encoding capabilities in 
the form of TFO protocol versions allows an effective TFO version handling. Prefera- 
bly, immediate codec type optimization becomes effective only in TFO protocol 
version 5 or higher. If either the local or the distant side is using a lower TFO proto- 
col version, no immediate codec type optimization is used. Hence, the protocol is 
compatible with older versions that do not include immediate codec type optimiza- 
tion. A switch to a different codec type will nonetheless be possible using the ordi- 
nary codec type optimization routines that have been defined for the Mismatch or 
Operation state described above. 

The exchange of the TFO protocol version has further advantages. For example, the 
usage of specific features and/or encoding formats may be associated to specific 
versions of the TFO protocol. Hence, when receiving a TFO_REQ/TFO_ACK message 
with a specific version number, the receiving side knows which features and/or 
encoding formats may be used. 

In the present scenario the smallest defined TFO protocol version number is 0.0. It 
stands for all TFO protocol versions before 5.3. All numbers between 0.0 and 5.3 
may be reserved for future use. If the local and the distant version number differ, 
the smaller version number shall have precedence and shall be applied on both sides. 
The table of Fig. 10 gives an overview over an exemplary TFO version handling 
mechanism. 
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For example, the knowledge of the protocol version number may be used to decide 
on the encoding format to transport the so called "TFO configuration parameters". 
After a successful TFO negotiation, when the protocol is in the Operation state, either 
old or new (so called "generic") configuration frames can be used because both sides 
know the TFO version of the opposite side and can flexibly decide how to handle any 
subsequent changes of the encoding format. A possible scenario for the handling of 
configuration frames is depicted in the right hand column of the table that is shown 
in Fig. 10. 

For example, the following constellations can be handled: 

a) V4.x <-> V4.x: use old Configuration frames or 

the TFO_REQ_L and TFO_ACK_L protocol. 

b) V4.x <-> V5.x: use old Configuration frames or 

the TFO_REQ_L and TFO_ACK_L protocol. 

c) V5.x <-> V5.x: use new Configuration frames or 

the TFO_REQ_L and TFO_ACK_L protocol. 

Furthermore, the exchange of the protocol version number also allows more sophisti- 
cated decisions in the TFO decision block of Fig. 8. For example, a decision "No TFO 
at all" may result from the fact that the TFO version numbers or other configuration 
parameters reveal that the current call scenario is not favorable for TFO. In TFO 
protocol version 4.x.y TFO configuration parameters are exchanged as so called "old 
configuration frames" in a very specific and somehow scattered form within the 
speech and no-speech frames. Accordingly, the implementation needs some effort. 
With the early exchange of the TFO protocol version number it is now possible that a 
version 5 transcoder rejects the TFO attempt of a version 4 transcoder and thus has 
a potential for cost saving. 

As has become apparent from the above, the exchange of information about the 
encoding capabilities leads to a faster TFO setup as regards an optimal encoding 
format like AMR-WB. Furthermore, the extension blocks used for signaling the 
encoding capabilities guarantee that the TFO messages are better prepared for 
further extensions. The TFO version negotiation described above allows to flexibly 
decide in an early stage of the TFO protocol whether TFO setup is desirable or not. 
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Although embodiments of the method and device of the present invention have been 
illustrated in the accompanying drawings and described in the foregoing detailed 
description, it will be understood that the invention is not limited to the embodiments 
disclosed, but is capable of numerous rearrangements, modifications and substitu- 
tions without departing from the spirit of the invention as set forth and defined by 
the following claims. 



WO 03/092312 



PCT/EP03/04268 



- 22 - 



CLAIMS 

1. A method of initiating the bypassing of a pair of transcoding operations 
5 performed in series by a first transcoder arranged together with a first 

communication terminal on a local side of a communication network and 
by a second transcoder arranged together with a second communication 
terminal on a distant side of the communication network, comprising re- 
ceiving from the distant side information about an encoding format cur- 
io rently in use on the distant side and about encoding capabilities of the 

distant side and transmitting to the distant side information about an en- 
coding format currently in use on the local side and about encoding capa- 
bilities of the local side to enable on one or on both sides a change of the 
encoding format currently in use prior to initiating the bypassing of the 
is transcoding operations. 

2. The method of claim 1, further comprising deciding about the change of 
the encoding format even if compatible encoding formats are currently 
used on both sides. 

20 

3. The method of one of claims 1 or 2, wherein the information on the encod- 
ing capabilities of the distant side is used to determine an alternative en- 
coding format that is supported on both the local and the distant side. 

25 4. The method of claim 3, wherein the change of the encoding format is ef- 

fected on the basis of the alternative encoding format. 

5. The method of one of claims 1 to 4, wherein the information about the 
encoding capabilities includes the version of a bypassing protocol sup- 

30 ported by the respective transcoder. 

6. The method of one of claims 1 to 5, wherein the information about the 
encoding capabilities includes a list of encoding formats supported by the 
respective communication terminal. 



35 
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7. The method of one of claims 1 to 6, wherein the change of the encoding 
format is effected with the purpose of establishing an optimal encoding 
configuration on the basis of compatible encoding formats on both sides. 

8. The method of one of claims 1 to 7, further comprising changing the en- 
coding format currently in use and notifying the distant side thereof prior 
to entering an operational state bypassing the transcoding operations. 

9. The method of one of claims 5 to 8, wherein a bypassing protocol is 
aborted if incompatible protocol versions are used on the two sides and/or, 
in the case of compatible protocol versions, the encoding format is 
changed in a contact state of the bypassing protocol that is followed by an 
operational state in which the transcoding operations are bypassed. 

10. The method of one of claims 1 to 9, wherein the information about the 
encoding format includes a codec type that is used to encode speech sig- 
nals into an encoded data representation. 

11. The method of one of claims 1 to 10, wherein the information on the en- 
coding capabilities of the distant side is used to look up a subset of encod- 
ing formats supported on the distant side, wherein that subset is compared 
with the encoding formats supported on the local side and wherein the 
best encoding format in common is chosen to initiate bypassing of the 
transcoding operations. 

12. The method of one of claims 1 to 11, wherein the information about the 
encoding format currently in use and about the encoding capabilities are 
included in a message requesting the initiation of a bypassing protocol or a 
message acknowledging such a request. 

13. The method of claim 12, wherein the information about the encoding ca- 
pabilities is appended in the form of one or more individual information 
blocks to the message. 

14. The method of claim 13, wherein a first appended block includes the ver- 
sion of a bypassing protocol and an indicator that indicates if the first ap- 



WO 03/092312 



PCT/EP03/04268 



-24- 

pended block is followed by a second appended block that includes a list of 
supported encoding formats. 

15. The method of one of claims 1 to 14, wherein the method is performed in 
context with setting up of a tandem free operation (TFO) between the two 
communication terminals. 

16. The method of one of claims 1 to 15, wherein at least one of the commu- 
nication terminals uses at least one encoding format in the form of a codec 
type to encode speech signals into an encoded data representation and 
wherein messages are sent between the two transcoders to determine if 
the communication terminals have at least one codec type in common and 
if this is the case to establish a data connection between communication 
terminals without having the need to insert transcoding functions into a 
signal path between the communication terminals. 

17. The method of claim 15 or 16, wherein between the transcoders first mes- 
sages are exchanged that contain the information about the encoding for- 
mat currently used by the respective communication terminal and that 
contain the further information about the encoding capabilities of the re- 
spective communication terminal or transcoder. 

18. The method of one of claims 15 to 17, wherein a second message is ex- 
changed between the transcoders as a response to the first message if 
both reported codec types match or regardless of such a match. 

19. A method of initiating a tandem free operation (TFO) in a communication 
network for speech communication between a first communication terminal 
and a second communication terminal, wherein at least one of the termi- 
nals uses at least one codec type to encode speech signals into an encoded 
data representation, wherein the communication network includes a first 
transcoder and a second transcoder, and wherein messages are sent from 
the first transcoder to the second transcoder and vice versa to determine if 
both communication terminals have at least one codec type in common 
and if this is the case to establish a data connection between the first 
communication terminal and the second communication terminal without 
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having the need to insert transcoding functions into a signal path between 
the first and the second communication terminal comprising the steps of: 

- exchanging first messages between the transcoders that contain infor- 
mation on the encoder type currently used by the communication ter- 
minals and further information on encoding capabilities of the 
respective communication terminal and 

- exchanging a second message between the transcoders as a response 
to the first message if both reported codec types match or regardless of 
such a match. 



10 



20. The method of claim 19, wherein the information on encoding capabilities 
includes a, TFO version number that is used by the receiving transcoder to 
look up a subset of at least one of an active codec set that is in a manda- 
tory manner supported in the specific TFO version and a supported codec 

15 list, wherein the transcoder compares that subset with the codec types 

supported by the associated communication terminal and wherein the best 
codec type in common is chosen to enter into TFO. 

21. A computer program product comprising program code portions for per- 
20 forming the steps of one of claims 1 to 20 when the computer program 

product is run on one or more computing units of the communication net- 
work. 

22. The computer program product of claim 21, stored on a computer readable 
25 recording medium. 

23. A device for processing signals in context with the initiation of the bypass- 
ing of a pair of transcoding operations performed in series by a first 
transcoder arranged together with a first communication terminal on a lo- 
se cal side of a communication network and by a second transcoder arranged 

together with a second communication terminal on a distant side of the 
communication network, comprising a component for receiving information 
about an encoding format currently in use on the distant side and about 
encoding capabilities of the distant side and a component for transmitting 
35 information about an encoding format currently in use on the local side and 

about encoding capabilities of the local side to enable on one or on both 
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sides a change of the encoding format currently in use prior to initiating 
the bypassing of the transcoding operations. 

24. A transcoder including the device of claim 23. 

25. The transcoder of claim 24, further comprising a component for evaluating 
local and distant encoding information and for controlling the change of the 
encoding format. 

26. A communications system including the transcoder of claim 24 and a con- 
troller for evaluating local and distant encoding information and for control- 
ling the change of the encoding format. 

27. The communications system of claim 26, wherein the controller is included 
in a BTS or a BSC. 
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Bit 


Description 


Comment 


Bit 1 




normal IS-Message Sync Bit, constant. 


Bit 2..6 


Selector 


Indicates if and which further extension_blocks are following. 
Coding for bits 2.3.4.5.6: 

00000: nothing is following after this TFO_Version 

00001: One (or more) alternative Codec Type(s) is (are) following, 10101: 

reserved (used by the ISJHeader) 

all other codes: reserved for future use. 


Bit 7..10 


Ver 


This field contains the TFO Version number 


Bit 11 


"0" 


normal IS-Message Sync Bit, constant 


Bit 12.. 15: 


Sver 


This field contains the TFO Subversion number 


Bit 16.. 18: 


CRC 


3 CRC bits protecting Bits 2 to 10 and 12 to 15 


Bit 19..20: 


EX 


The normal 2 bits for ISJvlessage Extension: 
00: No other extension block follows 
1 1 : An other extension block follows 



Fig. 6a 



Bit 


Description 


Comment 


Bit 1 


"0" 


normal IS-Message Sync Bit, constant. 


Bit 2 


PAR_SeI 


Differentiates this ExtensionJ3lock 

0: Parameters included in PAR field: Simple CodecJJst_Extension 
1 : Length Indicator (Li) included: Parameters follow in subsequent 
Extension Blocks 


Bit 3..10 


CoiD 


This field identifies the CodecJType for which the subsequent attributes are 
valid. The same coding as in the Codec_x Extension__Block is used (long form) 


Bit 11 




normal IS-Message Sync Bit, constant 


Bit 12.. 15: 


LI / PAR 


If Par_Sel==1: LI: Length Indicator: 
0000: reserved; 

0001: one other Extension_Block follows, etc. 

If Par Sel==0: PAR: Codec specific definition of these four bits 


Bit 16..18: 


CRC 


3 CRC bits protecting Bits 2 to 10 and 12 to 15 


Bit 19..20: 


EX 


The normal 2 bits for ISJvlessage Extension: 
00: No other extension block follows 
1 1 : An other extension block follows 
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BSC (loc) 



BTS 



X 



(loc) 1 



TFO_NO 
I 



TRAU (loc) I 

L ~ ' 



[ TC(dis) | |~ RNC(dis) 



Wakeup 



Rate Control within 
full local set 
by BTS 



TFO Report 
(dis Par) 



Change to 
optimal 
Configuration 
(AMR-WB) 

on local 
Air Interface 



New Config 



Wakeup 



PCM samples 



First Try 



First 



TFO„REQ (AMR, NB_ACS, Ver, AMR-WB) 



Try] 



MSC (dis) 



Rate Control within 
full distant set 
by RNC 



TFO_REQ (AMR, NB_ACS, Ver, AMR-WB) 



TFO Decision: immediate Optimisation 
to AMR-WB TFO, do not go into NB TFO 



Con_Dis 
(dis Par) 



Contact 



T 



Contact 

T 



TFO Report (optimal Configuration) 1 



TFO_ACK (AMR, NB_ACS, Ver, AMR-WB) 



TFO_ACK (AMR, NB_ACS, Ver, AMR-WB) 



Contact 



Con_Req (WB) 



Contact 



TFO_ACK (AMR-WB, Ver) 



I 



Contact 



Contact 



New Config (AMRAAB) 



TFO_ACK (AMR-WB, Ver) 



Wait_RC | 



TFO_Soon 
CMR=<RCi 



TFO_ACK (AMR-WB, Ver) 



Wait RC 



RCJReq (=<RCi) 



Change to 
optima! 
Configuration 
(AMR-WB) 

on local 
Air Interface 



New Config 



Steps assjiown in Fig. 9 



Fig. 8 
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BSC(loc) 1 1 BTS(loc) 1 
1 , .11. , 


| TRAU (loc) 


I 


TC (dis) ( 


| RNC (dis) | | MSG (dis) | 





Steps as shown in Fig. 8 



Rate Control within 
subset by BTS 



|TFO_MAYBE| 
-r 



BTS stops 
Time Alignment 



TFO Soon 



TFO ACK 



Rate Control within 
subset by RNC 



Time_Align_Req () 



Time_Align (not sup) 



RC_Ack 0 



TFO TRANS 



Konnect | 



TFO Frames 



Konnect | 



TFO TRANS 



CMR=<RCs, |Operationj 



„TFO On 



| TFO_YES~| 



Rate Control within 
common set by BTS 



Delay and distant TFO 
parameters known 

^ TFO Report 
(dis Par) 



Con_Req (dis) 



Con_Ack (loc) 



Con_Req (loc) 



Con_Ack (dis) 



TFO Frames 



| Ope rati oiT 



Exchange of TFO frames 



Con„Req (dis) 



Con_Ack (loc) 



Con_Req (loc) 



Con_Ack (dis) 



J RC_Req(=<RCs) 



a potential Time 
Alignment attempt 
is rejected 



Rate Control within 
common set by RNC 



RC_Ack () 



TFO Report (optimal Configuration) 



RC_Req () 



RC_Ack 0 



Fig. 9 
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Features- 
Codec Type^ 


TFO Version 


Immediate 
Codec Type 
Optimisation 


Generic Configuration 
Frames 


GSM FR 
GSMJHR 

PCM CCD 


Optional. 

The TFO Version 
extension diock 
need not to be 
sent. 

If not contained in 
TFO Messages, 
oms lower than 
5.3, 

then Pre-REL-5 
handling 
shall apply 


Mandatory, 

if 

i ru version is 
5.3 or higher. 


If the TFO Version is lower than 
5.3 

men generic L,onngurauon 
Frames shall not be used. Only 
TFO_REQ_L and (TFO_ACK__L) 
shall be used. 

If the TFO Version is 5.3 or 
higher, then 

Generic Configuration Frames 
shall be used. TFO„REQ_L and 
TFO_ACK L shall not be used 
embedded into TFO Frames. 


FR AMR 
HR_AMR 
UMTS_AMR 
UMTS AMR2 
OHR_AMR 


Optional. 

The TFO Version 
extension block 
need not to be 
sent. 

If not contained in 
TFO Messages, 

nr iq ln\A/pr t*h^n 

\Jl \ J lUVVCI LI ICJI 1 

5.3, 

then Pre-REL-5 
handling 
shall apply 


Mandatory, 

if 

TFO Version is 
5.3 or higher. 


If the TFO Version is lower than 
5.3, then Generic 
ConfigurationFrames shall not be 
used. If the TFO Version is 5.3 
or higher, then 
Generic Configuration Frames 
shall be used. The parameter 

fiplrl in RFI -4 AMR Pnnflni iratfnn 
i iciu mi i\L.L i mii ix v^.ui u iy ui auui i 

frames shall be treated as 
undefined. TFO_REQ_L and 
TFO_ACK L shall not be used 
embedded into TFO Frames. 


FR_AMR-WB 
UMTS_AMR- 
WB 

OFR_AMR-WB 
OHR_AMR-WB 


Mandatory. 

The TFO Version 
extension block 
shall always be 
sent. 


Mandatory. 


Generic Configuration Frames 
shall be used. TFO_REQ_L and 
TFO ACK L shall not be used 
embedded into TFO Frames. 



Fig. 10 
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